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System, Method and Computer Program Product 
FOR Allowing a Carrier to Act as a Credit- Approval 
Entity for E-commerce Transactions 

5 Related Application(s) 

The present application claims the priority of a provisional application filed 
June 12, 2000 under serial number 60/210,966, and which is incorporated herein by 
reference in its entirety. The present application is further related to a co-pending 
1 0 application filed concurrently herewith under the title "SYSTEM, METHOD AND 

computer program product for charging for competitive IP- 
over-wireless SERVICES" and docket number XACCTP004 and naming 
Limor Schweitzer as inventor, and a co-pending application filed concurrently 
herewith under the title "SYSTEM, METHOD AND COMPUTER PROGRAM 
1 5 PRODUCT FOR PREPAID WIRELESS VOICE COMMUNICATION AND IP 
SERVICES" and docket number XACCTP005 and naming Limor Schweitzer as 
inventor, which are each incorporated herein by reference in their entirety. 



Field of the Invention 

The present invention relates to e-commerce, and more particularly t< 
administering payment for e-commerce transactions. 



Background or the Invention 

25 

Over the last several years, businesses have been attracted to the rapidly 
growing number of personal computer users. More specifically, these businesses 
have realized the potential customer base of the so-called "on-line users." On-line 
service providers such as America Online, CompuServe, and Prodigy have provided 
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easy access to computer networks such that a large captive audience of on-line 
consumers has emerged. 

In the business arena, a merchant can, with an Internet address and a 
hypertext editor, develop a first hypertext document called a "home page" (or 
"virtual storefront") which a user sees when he enters the Web at the merchant's Web 
server. That home page may provide descriptions of products and services through 
the use of media such as graphic images, sound, and hypertext link choices. The 
information allows the consumer to find the product or service he desires to 
purchase. The resuh is an easily accessible system for purchasing anything from a 
journal page and investor advice to travel tickets and golf clubs. 

Several techniques for creating cashless commercial transactions exist for 
sales over networks such as the Internet. The most common technique involves the 
use of credit cards where credit is extended to a cardholder by a financial institution 
to cover purchases from participating merchants. The financial institution pays the 
merchant the purchase price less a service charge fee and later bills the cardholder 
for the purchase price. During use, the merchant gets credit approval from credit 
card companies using weak customer identification. Further, the merchant 
communicates over secured link with the credit card company and provides 
customer identifiers including credit-card number, customer name, expiration date, 
billing address, etc. Of course, this information must be collected from the customer 
during each transaction. 

Another system that allows for purchases without the use of cash is a debit 
system. One example of such a system is NetBill. In such systems, a large server 
maintains accounts for both merchants and consumers. These NetBill accounts are 
linked with conventional financial institutions. When a consumer chooses to 
purchase goods or services from a merchant, a NetBill fransaction is commenced in 
which the product or service is transferred, if possible, e.g., a journal page, the 
consumer's account is debited, and the merchant's account is credited. When 
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necessary, funds in the consumer's NetBill account can be replenished by electronic 
transfer from a bank or by credit card. Also, funds in the merchant's NetBill account 
are made available by depositing the funds in the merchant's bank account. Similar 
to the credit system, the merchant must communicate with the debit system and 
5 provide customer identifiers including a debit account identifier, customer name, 
billing address, etc. Again, this information must be collected from the customer 
during each transaction. 

By requiring the merchant to collect the above credit and/or debit account 
10 information for each transaction, both the merchant and the customer are 
inconvenienced in terms of time and costs. There is therefore a need for an 
improved technique of administering payments for transactions carried out over the 
Internet. 
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DlSCLOSURE OF THE INVENTION 

A system, metliod and computer program product are provided for paying for 
5 a transaction over the Internet. Initially, information is received utilizing a network. 
Such information includes an Internet Protocol (IP) address of a user and an amount 
of payment due. An account is then identified using at least a portion of the 
information, i.e. the IP address. Thereafter, payment is administered for the payment 
due by billing against the account. In a preferred embodiment, the present invention 
10 may be carried out by a network service provider, or carrier, who is capable of 
providing the user with access to the network. 

In one embodiment of the present invention, the account may take the form 
of a debit account. Further, a site may send the information to the network service 
1 5 provider, or carrier in response to the user carrying out a transaction using the site. 
As an option, the information may fiirther include port numbers which are associated 
with applications facilitating the required transactions. 

In another embodiment of the present invention, user data may be identified 
20 by the network service provider, or carrierbased on the received information. Such 
user data may then be sent to the site. Optionally, the user data may include 
shipping information. Further, permission may be requested from the user prior to 
sending the user data to the site. 

25 As an option, the administration of payment may be limited based on a rule 

agreed upon by the site, the network operator or carrier, and the consumer. Further, 
the network service provider, or carrier may collect a fee from the site. Such fee 
may take the form of a percentage of the payment due. 
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In various embodiments, the foregoing techniques may be carried out by a 
financial institution offering credit in conjunction with a network service provider. 
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Brief Description of the Drawings 

Figure 1 illustrates a method for paying for a transaction over the Internet; 

5 Figure 2 illustrates an exemplary flow process associated with the method of 

Figure 1; 

Figure 3 illustrates yet another exemplary flow process associated with the 
method of Figure 1; 

10 

Figure 4 shows an exemplary accounting system and the manner in which it 
interfaces with a conventional General Packet Radio Service (GPRS) system for 
collecting IP content usage information and call description record information; and 

1 5 Figure 5 illustrates a diagram showing a flow of information using the system 

of Figure 4. 



20 
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Description of the Preferred Embodiments 

Figure 1 illustrates a method 100 for paying for a transaction over the 
5 Internet. Initially, in operation 102, information is received from an e-commerce site 
utilizing a network. In one embodiment, the information includes an Internet 
Protocol (IP) address of a user and an amount of payment due. As an option, the 
information may further include port numbers, and/or any other information that 
may help identify the user and/or an associated transaction. For security purposes, 
10 the information may be received over a secure link. 

It should be noted that the information may be received from a site in 
response to a user carrying out a transaction using the site. For example, the user 
may indicate that he or she wishes to purchase goods or services using the site. 
1 5 Thereafter, the site may send the information for payment purposes. In the 

alternative, the information may be received from the user or a combination of the 
user and the site. 

Upon receipt of the information, an account is identified in operation 104 
20 using at least a portion of the information, namely the IP address and port numbers. 
This may be accomplished by keeping a database that links IP address and port 
numbers to corresponding accounts. Tables may be constructed when an account is 
established by a user for this purpose. In one embodiment, the account may be a 
debit, credit or any other type of desired account adapted to transfer value for 
25 payment purposes. In the case of a debit account, regulatory credit checks may be 
avoided. 

Thereafter, in operation 106, payment is administered for the payment due by 
billing against the account. This may be accomplished by sending a check to the site 
30 on which the transaction occurred, transferring money to an account owned by the 
site, or by other value transfer mechanisms. In a preferred embodiment, the present 
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invention may be carried out by a network service provider or, in other words, 
carrier, who provides the user with access to the network. 

In another embodiment, the present invention may be carried out by a 
5 financial institution offering conventional credit through credit cards in conjunction 
with a network service provider who provides the user with access to the network. 
During each transaction, the user may provide his/her credit card information to the 
financial institution, which is then correlated with the user account information 
stored with the network service provider. This leads to strengthened user 
1 0 authentication that greatly reduces firaud. 

As an option, user data may be identified based on the received information. 
Such user data may then be sent to the site for various purposes. In one 
embodiment, the user data may include shipping information that is included in the 
1 5 aforementioned tables. By providing the site with such shipping information, goods 
may be delivered without asking the user to enter any additional information. 
Optionally, permission may be requested from the user prior to sending the user data 
to the site. In other embodiments, the user data may include any information relating 
to the user and facilitates e-commerce. 

20 

In order to more effectively interface with the e-commerce sites, a hierarchy of 
purchasable item categories may be maintained. Further, each e-commerce site may be 
required to sign an agreement to tag goods and services with a category identifier so that 
pre-selection can apply. In other words, the owners of the debit accounts can pre-select 

25 purchasable categories when the account is set up. To this end, the administration of 
payment may be limited based on a user-determined rule. In particular, parents may be 
permitted to control how kids spend their money, and corporations may limit the scope 
of travel expenses. It should be noted, however, that the administering of payment may 
be limited by any rule. For example, the payment may be simply limited by a maximum 

30 purchase price, etc. 
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In order to generate revenue, a fee may be collected from the site for each 
transaction. In one embodiment, such fee may take the form of a percentage of the 
payment due. 



5 Figure 2 illustrates an exemplary flow process associated with the method 100 of 

Figure 1. As shown, three parties may be involved including a user 200 communicating 
from a computer, an e-commerce site 202 communicating from a site on the Internet 
which is accessible to the user via a conventional network cormection. It should be 
noted that any type of protocol may be used to interface with the e-commerce site 202 

10 including, but not limited to hypertext transfer protocol (HTTP), wireless application 

program (WAP), or any other protocol allowing the user 200 to communicate with the e- 
commerce site 202. Further included in the process is a carrier 204 which has a 
relationship with the user 200. In particular, the carrier, or network service provider, 
204 maintains an account for the user 200. In the present description, the network 

1 5 service provider is defined as being capable of providing the user with access to the 
network. 



As shown in Figure 2, the user 200 interfaces with the e-commerce site 202 
in order to browse goods and services and identify the prices thereof. See operation 
20 208. During this operation, an IP address and port numbers are conveyed. It should 
be noted that this may be accomplished manually or, more preferably, automatically 
upon receipt of a message using Internet Protocol. As is well known, the IP address 
and port numbers may be automatically retrieved from such a message. 

25 Next, the e-commerce site 202 may indicate a discount to be received if 

various goods and services are purchased. Further, the carrier 204 may be identified 
in operation 210. Once the price is identified, the user 200 may indicate whether he 
or she wishes to purchase the goods or services in operation 212. 
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in response to the user 200 asking to purchase the goods or services, the e- 
commerce site 202 sends the IP address, port numbers and price of the goods or 
services to the carrier 204. Note operation 214. It should be noted that the price 
may already reflect the discount set forth in operation 210. In response thereto, the 
5 carrier 204 may provide a uniform resource locator (URL) to which the user 200 
must link, as indicated in operation 216. This link is then relayed to the user 200 
fi-om the e-commerce site 202 in operation 218. Ideally, such is relayed inside a 
secured carrier network. 

] 0 The foregoing URL allows the user 200 to view a form that gives permission 

to the carrier 204 to pay the e-commerce site 202 the price using the debit account 
established between the user 200 and the carrier 204. As an option, such permission 
may further include providing the e-commerce site 202 a shipping address which the 
carrier 204 obtained when the debit account was established, or updated thereafter. 

1 5 See operation 220. It should be noted that the permission may be granted by the user 
200 to the carrier 204 by simply chcking an icon or any other more or less 
sophisticated procedure. 

In response to the permission being granted in operation 220, the carrier 204 
20 provides the e-commerce site 202 with a confirmation number and the shipping 

address in operation 222. As such, the e-commerce site 202 is capable of shipping 
any goods to the user, or providing a receipt therefor. A confirmation is then sent 
from the e-commerce site 202 to the user 200 in operation 224. 

25 With continuing reference to Figure 2, a fee may be charged to the e- 

commerce site 202 by the carrier 204 in operation 226. As an option, this may be a 
percentage of the payment due for the services, and may be simply deducted from 
the amount due to the e-commerce site 202. Finally, the e-commerce site 204 may 
ship any purchased goods to the user 200 using the shipping information, as 

30 indicated in operation 228. 
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It should be noted that security cannot be infringed because the customer 
confirmation is given by the user while accessing a site that is internal to carrier 204, 
possibly with an IP address that cannot be accessed from outside the carrier's 
5 network. The URL of the internal site may be "pushed" at the browser by the e- 
commerce site 204 (who can not access that URL because it is on the wrong side of 
a firewall). 

Figure 3 illustrates yet another exemplary flow process associated with the 
10 method 100 of Figure 1. As shown, three parties may again be involved including a 
user 300 communicating fi-om a computer, an e-commerce site 302 communicating 
from a site on the Internet which is accessible to the user via a conventional network 
connection. Further included in the process is a carrier gateway 304 which has a 
relationship with the user 300 similar to as before. 

15 

In the present description, a gateway is a network point that acts as an 
entrance to another network. The Internet typically consists of gateway nodes and 
core nodes, where gateway nodes interface with host nodes that generally reside at 
user premises. The computers of network users and the computers that serve content 
20 (such as Web pages) are host nodes. The computers that control traffic within a 

company's network or with a local Internet service provider (ISP) are gateway nodes. 
In the network for an enterprise, a computer server acting as a gateway node is often 
also acting as a proxy server and a firewall server. Gateways also involve the use of 
router and switch. 

25 

As shown in Figure 3, the user 300 initially transmits a request for prices on 
goods or services in operation 306. This request is then received by the carrier 
gateway 304 which in turn relays the request in operation 308. Such request may 
further identify the carrier associated with the gateway 304. 

30 
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In response thereto, the e-commerce site 302 sends an indication of the price 
to the user 300 by way of the carrier gateway 304. Note operation 310. This request 
is then relayed from the carrier gateway 304 to the user 300. As shown, the price 
may be modified in order to generate revenue for the carrier associated with the 
5 carrier gateway 304. The user is then given the opportunity to purchase the goods 
and services in operation 313 which is, in turn, relayed from the carrier gateway 304 
to the e-commerce site 302. See operation 314. 

In addition to relaying the purchase request in operation 314, a user identifier 
1 0 and/or shipping information may also be fransmitted to the user e-commerce site 302 
from the carrier gateway 304, as indicated in operation 316. If such information is 
sufficient, the e-coramerce site 302 may indicate to the carrier gateway 304 that the 
purchase is complete in operation 318. Such message may then be relayed from the 
carrier gateway 304 to the user 300 in operation 320. 

15 

With continuing reference to Figure 3, the purchase price may be charged to 
the user 300 by the carrier gateway 304 in operation 322. Next, such money is 
relayed to the e-commerce site 302 in operation 324. As an option, the money given 
to the e-commerce site 302 may reflect a fee for the services provided by the carrier 
20 gateway 304. 

It should be noted that the carrier may include an IP network, WAP network, 
or a combination thereof While implementing transactions carried out over an IP 
network is commonly known to those of ordinary skill, using a WAP network carrier 
25 may require integration with a wireless network. 

Figure 4 shows an exemplary accounting system 400 and the manner in 
which it interfaces with a General Packet Radio Service (GPRS) system 402 for 
collecting IP content usage information and call description record information. By 
30 providing such an interface, transactions involving a wireless network are facilitated. 
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As shown, the exemplary system 400 includes a plurality of data gatherers 404 
which are in turn a component of a plurality of information source modules (ISMs). 
Such ISMs interface with the Serving GPRS Support Node (SGSN) and Gateway 
GPRS Support Node (GGSN) of the GPRS system 402 for receiving the call 
5 description records (CDRs) therefrom. 

This may be accomplished by receiving CDRs directly from the SGSN 
and/or GGSN. Also, the present invention may support the Ga protocol as described 
by European Telecommunications Standards Institute (ETSI) specs, accepting all 
1 0 types of CDRs produced by SGSN and GGSN. This provides mobility, short 

message service (SMS), and quality of service (QoS). It should be noted, however, 
that the accounting system 400 may interface the GPRS system by any desired 
means. 

] 5 In one embodiment, the call description record information may include 

conventional CDRs or any other data structure that is collected from the GPRS 
system, and is descriptive of calls that take place thereover. Further, the call 
description record information may be collected by the data gatherers 404 of the 
ISMs, which interface the GPRS system 402. Note Figure 4. 

20 

As an option, the system 400 may use the received CDRs to map IP content 
events to ISMs, resulting in a new type of call description records, XDRs. Such 
XDR's get fed into rating engines and then to a standard content based billing 
module 406. For more information on how one exemplary content based billing 
25 module 406 operates, reference may be made to PCT application W09927556A2 
entitled "NETWORK ACCOUNTING AND BILLING SYSTEM AND METHOD" 
published June 3, 1999, and which is incorporated herein by reference in its entirety. 

Figure 5 shows a flow of information using the system 400 of Figure 4. As 
30 shown, a plurality of IP -enabled mobile communication units 502 are provided 
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which are adapted to connect to a base station BSS 504 over a Global System for 
Mobile Communication (GSM) 506 or any other wireless network. 

A packet tunnel 508 is then created from the handset through a SGSN of the 
5 BSS 504 to a router 510 logically located in the GGSN. From that router 510, the 
packets are outputted to the operator's IP network 512. A LDAP Radius server 514 
may be provisioned so that whenever mobile communication units belonging to 
these corporate customers "log-in" to the network, they will be given an IP address. 

1 0 The present embodiment may collect the accounting information from the 

different parts of the network, correlating GPRS info with IP content. As an option, 
this may be accompUshed in a manner set forth in a co-pending patent application 
filed concurrently herewith under the title "SYSTEM, METHOD AND 
COMPUTER PROGRAM PRODUCT FOR CHARGING FOR COMPETITIVE EP- 

1 5 OVER-WIRELESS SERVICES" and docket number XACCTP004 and naming 

Timor Schweitzer as inventor. Converged data records may then be sent to be rated 
and then sent to a conventional debit account mechanism 516. For more information 
on one possible implementation of a debit account mechanism 516, reference may be 
made to a co-pending application filed concurrently herewith under the title 

20 "SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR PREPAID 
WIRELESS VOICE COMMUNICATION AND IP SERVICES" and docket number 
XACCTP005 and naming Limor Schweitzer as inventor. 

While various embodiments have been described above, it should be 
25 understood that they have been presented by way of example only, and not 

limitation. Thus, the breadth and scope of a preferred embodiment should not be 
limited by any of the above-described exemplary embodiments, but should be 
defined only in accordance with the following claims and their equivalents. 

30 
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